GraphQL Schema
標準の拡張子は.graphql
defaultでnullable
String!のように!を付けることでnull非許容になる
Learn
Introduction
Schemas and Types
Queries
Mutations
Subscriptions
Validation
Execution
Response
Introspection
Best Practices
Best Practices
Thinking in Graphs
Serving over HTTP
Authorization
Pagination
Schema Design
Global Object Identification
Caching
Performance
Security
Federation
typeで型を定義する
任意のEntityの型を構成する
QueryとMutationもその1つ
GraphQL上の扱いは、任意のEntityと同じ
慣習的にエントリポイントとして使われる
GET系の諸々をQueryに集約する (別にQueryという命名でなくても良い)
GPT-4.icon
table:table
種類 役割
:----------- :----------------------------
type データの「形」を定義する
Query 「データ取得」の入り口を定義する
Mutation 「データ変更」の入り口を定義する
input Mutationで使うリクエスト用オブジェクトを定義する
(option) enum 値の候補を列挙する
任意のEntityを定義するのも、決まったQuery/Mutationを定義するのも、両方とも同じtype Hoge {..}で書くの、かなり意味がわからないmrsekut.icon
1. type：データの形を定義する
code:graphql
type Book {
id: ID!
title: String!
author: String!
}
typeはオブジェクトの形を決める
→ 例えば「本」というデータは、id, title, authorを持つ
ID!とかString!みたいに書く
!は「絶対にnullにならない」という意味
配列は [Type]、非null配列は [Type!]! みたいに書く
4. enum（オプションだけどよく使う）
code:graphql
enum BookGenre {
FICTION
NONFICTION
MYSTERY
FANTASY
}
type Book {
id: ID!
title: String!
author: String!
genre: BookGenre!
}
enumは「選択肢が限られている値」を作る
文字列だけど、事前に決めたものだけ使わせることができる
---
🛠️ 基本型（スカラー型）
table:table
型名 説明
:--------- :-----
ID 識別子（実体はStringだけど意味的にID）
String 文字列
Int 整数
Float 小数
Boolean true/false
APIはRESTのエンドポイントの集合ではなく、型の集合としてとらえられるようになります
このデータ型の集合をスキーマと呼び
キーワード
引数
エイリアス
同じクエリを同時に参照できないので、別名を与える
フラグメント
関数のように同じデータの指定をまとめられる
操作名query hogehoge
変数
code:graphql
query ($login: String!) { # !はnullにならないことを示す
user(login: $login) {
bio
name
}
}
mutaion
データの更新をする
型
!: Not Null
用語
Fileds...取得データのフィールド値
Arguments...フィールドに渡す引数
Aliases...取得結果のエイリアス(取得結果の名前変更)
Operation Type...操作タイプ(query, mutation, subscriptionのどれか)
Operation Name...操作名
Variables...クエリに渡す引数(フィールドに動的に値を渡せる)
Directives...取得結果の構造にフィールドを含めるか否かを決められる(@include, @skip)
Fragments...フィールド値の集合(共通化に便利)
Inline Fragments...queryに直接埋め込める(取得した型によって結果を分けられるので便利)
ブラウザ上でGraphQLのスキーマ見れるやつ
どういう感じで定義するのが良いのか？
例えばnullableかどうかとはかは、通常のmodelingと同じ様に厳格にやるべきなのか
DBのtable設計と似たように考えるのか？
あるいはもっとフランクに扱っても良いものなのか？
以下は互いに依存しないのか？
GraphQL Schema
server/clientのEntityの定義
DBのtable
1個変更したらいずれも変更しないといけなくなるのか、設計次第でどうにでもなるのか